One of the reasons why wget was chosen over curl initially was that it has a much nicer progress bar showing file name, download size, download speed and remaining time, whereas curl has a very basic and ugly progress bar that provides none of the aforementioned details.

Given that we recommend and depend on wget for many other things in the documentation and wget can be easily installed using winget alongside many other components that are not available on Windows, I am not convinced that this is a necessary change.

Understood. The thing is if you want to integrate zephyr setup into your tooling you have other more convenient options to download the rest so then wget would only be required to run this script which is really not necessary. So what about keeping wget the default and give an option via flag / fallback to use curl?

If you accept this solution I would also like to add it as option / fallback to macOS as it has also curl installed by default and wget would need to be installed separately.

Understood. The thing is if you want to integrate zephyr setup into your tooling you have other more convenient options to download the rest so then wget would only be required to run this script which is really not necessary. So what about keeping wget the default and give an option via flag / fallback to use curl?

7z, another utility not available by default on Windows, will need to be installed or provided in some way for this script to run; so, I do not really understand the desire to use curl on the basis that it is already available on Windows -- the script will not be able to run on vanilla Windows anyway.

The question is: why is it so hard to provide wget as with 7z, which you will need to provide anyway, in your tooling?

7z, another utility not available by default on Windows, will need to be installed or provided in some way for this script to run; so, I do not really understand the desire to use curl on the basis that it is already available on Windows -- the script will not be able to run on vanilla Windows anyway.

The question is: why is it so hard to provide wget as with 7z, which you will need to provide anyway, in your tooling?

Thanks for the clarification! I completely agree that 7z is unavoidable — it’s a required tool, so adding that dependency makes sense.

What I’m trying to highlight is that wget doesn’t really fall into the same category. Adding it introduces:

• Extra complexity: one more binary to download, host, and maintain. (mostly maintain the download links and check that the third party keeps the wget binary updated with the latest security patches by the wget team)
• Fragile indirection: depending on a third-party binary hosted in a third-party repo, downloaded through another third-party package manager (e.g. winget) that might not even be installed on the users computer (we often had that issue).
• Little to no benefit (in our scenario): the main difference is a progress bar, but in non-interactive/headless setups (which are fairly standard these days: ci, IDEs, toolchain installers, fleet management with remote installs) that’s not visible anyway.

In contrast, both macOS and Windows already ship with curl by default. Relying on built-in system utilities reduces external dependencies, improves reliability, and avoids unnecessary setup friction.

So my suggestion isn’t to drop wget (I think your point is perfect valid and for people who follow the guide and do it manually can benefit of these advantages), but to add curl as a fallback (and opt-in flag). That way, users benefit from system-provided tooling where available, and we don’t increase maintenance overhead or complexity.

It does actually increase the maintenance overhead for us ensuring the identical behaviour across two different tools and dealing with the potential bug reports related to this.

wget is referenced throughout the Zephyr documentation, including the Getting Started Guide, and installing/providing it should be almost effortless.

Also note that you will need a lot more than just wget to be able to set up Zephyr build environment; so, my suggestion is to just provide wget alongside many other tools you will need to provide anyway.

@nashif Sorry to bother, but could you please take a look at this discussion?

My point is not to remove wget, but to allow curl (which is available by default on both Windows and macOS) as a fallback/option. From a user perspective this:

• avoids adding an extra dependency that needs to be downloaded, hosted, and maintained,
• reduces potential setup friction in headless/CI environments,
• leverages system-provided tooling that both Microsoft and Apple already ship by default. (even most Linux distros)

I fully understand that 7z is unavoidable and must be provided separately, but unlike 7z, wget duplicates functionality that curl already covers. Adding it increases maintenance and dependency surface for no real benefit to end users (especially in non-interactive setups where things like progress bars don’t matter).

I think having curl as a supported fallback would improve robustness while keeping the developer experience smoother. Could you please weigh in?

@stephanosio

It does actually increase the maintenance overhead for us ensuring the identical behavior across two different tools and dealing with the potential bug reports related to this.

One way to reduce that overhead would be to standardize on the tool that is already preinstalled on two of the three supported operating systems (Windows and macOS) and also available on most Linux distributions. Then the only additional case to handle would be Linux systems where curl is not already present.

wget is referenced throughout the Zephyr documentation, including the Getting Started Guide, and installing/providing it should be almost effortless.

Installing wget is still less effortless than using tooling that’s already shipped with the operating system and supported by the OS Maintainers (Microsoft and Apple) compared to a random third part person who linked wget to winget. Leveraging built-in utilities avoids additional downloads and setup steps, and improves the out-of-the-box experience for all users.

Also note that you will need a lot more than just wget to be able to set up Zephyr build environment; so, my suggestion is to just provide wget alongside many other tools you will need to provide anyway.

Having multiple required dependencies doesn’t make adding another one cost-free — especially when it duplicates functionality already provided by the system. The fact that Zephyr requires Python, for example, could even argue in favor of using Python’s built-in download capabilities, rather than pulling in yet another external tool.

To me, the key point is that curl is a modern, system-provided utility, already present on the majority of supported platforms. Using it (either as the default or as a fallback) would reduce external dependencies, lower setup friction, and improve robustness without sacrificing functionality.

One way to reduce that overhead would be to standardize on the tool that is already preinstalled on two of the three supported operating systems (Windows and macOS) and also available on most Linux distributions. Then the only additional case to handle would be Linux systems where curl is not already present.

As previously explained, there is a good reason why wget was chosen over curl.

Installing wget is still less effortless than using tooling that’s already shipped with the operating system and supported by the OS Maintainers (Microsoft and Apple) compared to a random third part person who linked wget to winget. Leveraging built-in utilities avoids additional downloads and setup steps, and improves the out-of-the-box experience for all users.

Even if you replace wget with curl here, you will still need to install, just to list a few, git, cmake, ninja-build, device-tree-compiler via winget or some other means, all of which are maintained by not "OS Maintainers."

Replacing wget with curl here does very little to fix the "problems" you speak of when looking at the bigger picture.

Having multiple required dependencies doesn’t make adding another one cost-free — especially when it duplicates functionality already provided by the system. The fact that Zephyr requires Python, for example, could even argue in favor of using Python’s built-in download capabilities, rather than pulling in yet another external tool.

$ ls -lLh /opt/homebrew/bin/wget
-r-xr-xr-x  1 stephanos  admin   461K Sep 22  2024 /opt/homebrew/bin/wget

It might as well be free, don't you think?

My point is not to remove wget, but to allow curl (which is available by default on both Windows and macOS) as a fallback/option. From a user perspective this:

• avoids adding an extra dependency that needs to be downloaded, hosted, and maintained,
• reduces potential setup friction in headless/CI environments,
• leverages system-provided tooling that both Microsoft and Apple already ship by default. (even most Linux distros)

To set up a working Zephyr build environment, in addition to wget, you need git, cmake, ninja-build, device-tree-compiler, gcc, gcc-multilib, g++-multilib, and more. Based on your reasoning, with so many extra dependencies, it must be unfathomable to set up and maintain a working Zephyr build environment.

And on macOS the recommendation is to install a third party package manager which OS integration capability is questionable at least??

Homebrew is a very popular package manager on macOS and that is why we recommend using it. What else would you suggest then? Provide a 10-page instruction in the Getting Started Guide downloading and installing every component one by one?

wget is a well established GNU utility that is fairly popular. It is lightweight and incurs practically no overhead. Installing or providing it should be effortless and should not result in any worse overall user experience, practically speaking.

So instead of imposing this seemingly irrational fear of wget on others, just install or provide it.

If there is some other reason why you cannot install/provide wget, please enlighten me.

I don't think we'll reach an agreement here, which is why I pinged the other maintainer for a second opinion.

In the meantime, we’ve decided to go with a warning/note in the README. It’s not ideal, as it makes using Zephyr a bit less convenient, but for now it seems like the safest option: https://github.com/raspberrypi/pico-vscode/tree/main?tab=readme-ov-file#zephyr-notes

@stephanosio Just to confirm, currently for a successful build of Zephyr for Raspberry Pi Pico-series devices across Windows, MacOS and Raspberry Pi OS, the only other dependencies needed are 7zip, cmake, git, ninja and python, which can all be installed relatively easily from official sources, and the majority of which we're installing anyway for Pico SDK builds.

Regarding other dependencies, device-tree-compiler is not required for building (it's only used for error checking), and gcc etc are all install as part of the Zephyr SDK so don't need separate installation.

So wget is the only remaining dependency that is required for building, but which is not easily downloadable like all the other dependencies, hence us focussing on replacing wget and none of the other dependencies

EDIT: When I say installed, I mean by our Raspberry Pi Pico VS Code extension, which is what we're focussing on

EDIT: When I say installed, I mean by our Raspberry Pi Pico VS Code extension, which is what we're focussing on

Ok, so if I understand correctly, all the dependencies are automatically installed by the "Raspberry Pi Pico VS Code extension" using the pre-compiled binaries from the official sources, without using package managers like Homebrew and winget?

So wget is the only remaining dependency that is required for building, but which is not easily downloadable like all the other dependencies, hence us focussing on replacing wget and none of the other dependencies

I can see that obtaining pre-compiled wget binaries on Windows and macOS can be somewhat difficult when not relying on a package manager -- though, it should not really be a problem when using a package manager, which is the recommended approach in the documentation, as previously stated.

Assuming your VS Code extension automatically invokes the Zephyr SDK setup script, why not just provide a wrapper for wget that calls curl within the extension? (e.g. on Windows, add a directory containing wget.cmd calling curl to PATH when invoking setup.cmd)

EDIT: When I say installed, I mean by our Raspberry Pi Pico VS Code extension, which is what we're focussing on

Ok, so if I understand correctly, all the dependencies are automatically installed by the "Raspberry Pi Pico VS Code extension" using the pre-compiled binaries from the official sources, without using package managers like Homebrew and winget?

Yes, that's correct - currently we have no pre-requisites that the user has to install on Windows and RPi OS, and on MacOS they just need the XCode command line tools which can be installed with xcode-select --install, no Homebrew required

Assuming your VS Code extension automatically invokes the Zephyr SDK setup script, why not just provide a wrapper for wget that calls curl within the extension? (e.g. on Windows, add a directory containing wget.cmd calling curl to PATH when invoking setup.cmd)

Yes, that sounds like it could be a good workaround for now (@paulober could you have a look at doing that) - but we think a better fix would be this PR (expanded to other OSes) to fix the issue upstream in Zephyr, rather than hacking around with a wrapper which might break if the Zephyr download script changes the arguments it invokes wget with to something the wrapper doesn't handle

Assuming your VS Code extension automatically invokes the Zephyr SDK setup script, why not just provide a wrapper for wget that calls curl within the extension? (e.g. on Windows, add a directory containing wget.cmd calling curl to PATH when invoking setup.cmd)

That doesn't work because of your usage of DelayedExpansion. Executing a cmd script instead of wget binary causes this to get disabled => every !VAR! will fail after this call. It could be fixed by using if errorlevel 1 like comparisons for exit codes and many other places wouldn't need this feature but even if, that could only be fixed in next release so won't be an option for now.